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[57] ABSTRACT 

A system for managing sensitive data is described. The 
system prevents a system administrator from accessing 
sensitive data by storing data and identifier information on 
different computer systems. Each query is encrypted using 
two codes, the first code readable only by an identifier 
database and a second code readable only by a data access 
database. By routing the data path from a source terminal to 
the identifier database which substitutes an internal ID, then 
to the data access database and back to the source terminal, 
data security is significantly improved. 

15 Claims, 5 Drawing Sheets 
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Figure 1. Secure Data Management System 100 
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Figure 2B. Flow Diagram 200, continued 
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Figure 3A. This is the configuration of the most basic unit, without a log monitor. 
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Figure 3B. This is the configuration of the most basic unit, with a log monitor. 
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Figure 3D. 
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SECURE DATABASE MANAGEMENT FIG. 4 illustrates the use of multiple identifier database in 

SYSTEM FOR CONFIDENTIAL RECORDS one embodiment of the invention. 

USING SEPARATELY ENCRYPTED FIG. 5 illustrates a combination identifier and data request 

IDENTIFIER AND ACCESS REQUEST database under a common administrative control as imple- 

5 mented in one embodiment of the invention. 

This application claims benefit of Provisional Applica- 
tion Ser. No. 60/072,740, filed Jan. 27, 1998. DETAILED DESCRIPTION OF THE 



BACKGROUND OF THE INVENTION 
1. Field of the Invention 10 



INVENTION 



In the following detailed description, a method and appa- 
ratus for protecting sensitive data will be described. The 

This invention relates to protecting confidential infbrma- detailed description will set forth numerous specific details 

Uon. In particular, the invention prevents insiders with high to prov ide a thorough understanding of the invention, 

levels of computer access from accessing sensitive data. However, those skilled in the art will appreciate that the 

2. Description of Related Art invention may be practiced without the specific details. In 

Computer systems have long been used for processing other instances, well-known methods, procedures, protocols, 

sensitive information. Such systems typically include a components and circuits, for example, public and private 

database and a processor which manipulates large amounts key cryptography which is well-understood by those of 

of highly personal and confidential data. In order to protect ordinary skill in the art have not been described in detail so 

outsiders from accessing the confidential data, fire walls and 2Q as not to obscure the invention. 

encryption systems are often used to prevent unauthorized \ a 0 ne embodiment of the invention, the secure system is 
access to the data. Examples of traditional systems and implemented using a large network of subnetworked corn- 
methods used to prevent unauthorized access to sensitive puters. For example, the Internet represents a large network 
data include such mechanisms as user authentication, access which couples together subnetworks such as a local area 
location restriction, and user level access controls. Although 25 network or ethernet coupled computers. For optimal 
such systems are useful for preventing "outsiders" from security, each of the subnetworks described will be under the 
accessing confidential data, these systems are typically control of a different administrator. Each administrator will 
unable to protect the data from "insiders" who have been not have control over computers outside of the respective 
granted high enough system access privileges to bypass the subnetwork. By partitioning sensitive data and distributing 
security controls. In particular, it is very difficult to deny a 3Q storage and retrieval of sensitive data over different subnet- 
system administrator access to sensitive or confidential data, works of computers, the data will be protected from 
System administrators who have a high level of access improper access by an individual administrator of a subnet- 
can typically access most data on the computer system. As work. 

data on the computer becomes increasingly sensitive and fig. 1 illustrates a secure data management system 100 

valuable, the system administrator or other "trusted insider*' 3S used to implement one embodiment of the invention. A user 

increasingly has incentives to defeat the protection mecha- inputs data into a source terminal 104. Atypical user may be 

nisms of the system and sell the confidential data. Thus, a a doctor or other personnel with an appropriate level of 

system which is capable of storing confidential data in a access to request the needed data. In one embodiment, 

form that is inaccessible to high-level computer administra- source terminal 104 may be a computer, or other processing 

tors while still granting access to sensitive data to appropri- ^ device, including a personal computer. In an alternate 

ate parties is needed. embodiment, source terminal 104 is merely a terminal 

SUMMARY OF THE INVENTION coupled to a main frame computer or other processing 

device. The source terminal may be associated with a local 

Amethod for retrieving sensitive stored data is described. computer network or "source subnetwork" 106. Source 
A receiving terminal receives a request for data from a user 45 subnetwork 106 may be a plurality of computers connected 
and encrypts an identifier with a first code and a data access by a local area network. Source terminal 104 identifies or 
request with a second code. The identifier and data access collects information to identify the user, typically by ob tain- 
request are transmitted to a first database which decodes the ing passwords, handprints, fingerprints, retinal scans, or 
identifier and determines whether the user has authorization other appropriate identification mechanism. After verifica- 
to request the desired information. The first database then 50 tion of the user's identity, the user, for example, a doctor, a 
retrieves an associated access level and internal identifier. lawyer, drug enforcement personnel, government official or 
The first database forwards the still encrypted data access banker, who has a need to know the information, requests 
request with the associated access level and internal identi- access to specific information about a particular individual 
fier to a second database. subject which is processed by the secure data management 

The second database retrieves the information requested 55 system 100. The user can also be a computer program or 

in the data access request and in one embodiment, if the user system. 

has an appropriate access level, transmits the requested Source terminal 104 receives information from the user 

information to the receiving terminal. anc j combines the information into a data packet 116 for 

BRIEF DESCRIPTION OF THE DRAWINGS output to other sections of secure system 100. The data 

60 packet 116 is composed of two smaller data packets, an 

FIG. 1 illustrates a computer network for implementing identifier 112 and a data access request 124. Identifier 112 

one embodiment of a data management system, includes subdata packets such as user I.D. 118 and subject 

FIGS. 2A& 2B are flow diagrams illustrating a method of I.D. 120. The first subdata packet, user I.D. 118, includes 

implementing the data management system. information on the user such as information needed to 

FIGS. 3A,3B,3C and 3D illustrate different embodiments 65 identify the doctor requesting data. Such information may 

of a data management system utilizing the disclosed inven- include, but is not Limited to the last name, first name, middle 

tion. name, social security number, birth date, mother's maiden 
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name, driver's license, medical license number, state bar 
number, drug enforcement agency number, invoice number, 
fingerprint number, or other information necessary or useful 
for identifying the user requesting the data. Second subdata 
packet, subject I.D. 120, includes information about the 
subject. The information in the second subdata package 
includes data needed to identify the individual or entity 
relating to the data access request. Such information may, for 
example, include the last name, first name, middle name, 
social security number, birth date, birthplace, mother's 
maiden name, driver's license, street address, e-mail, file 
number, patient identification number, inmate identification 
number, account number, or name of company. 

A processor 108 associated with source terminal 104 
encrypts the identifier 112, including subdata packets 118, 
120 using a first encryption code. In one embodiment of the 
invention, identifier 112 also includes subdata packet 104 
which contains information or an address of the source 
terminal 104 which generates the subdata pack 116. The 
address of the source terminal may be included in subdata 
packet 104 as a globally unique identifier or "GUID." 

Data packet 116 also includes a second portion, the data 
access request 124. Data access request 124 contains the 
specifics on the data requested, such as a request for a lab 
result or a request to append a new progress note. Data 
access request 124 may also in one embodiment of the 
invention be a token. A token may be an instruction, index 
or code which specifies a memory address or other instruc- 
tion to be performed by the token recipient. The token 
authorizes communications to source subnetwork 106 to 
obtain the details of the data request. Processor 108 encrypts 
the data access request 124 in a second code. The data access 
request 124 is associated with the identifier 112 within data 
packet 116 such that external subnetworks of computers or 
processors can link the identifier 112 to the data access 
request 124. 

In medical applications, source terminal 104 is typically 
a computer in a source subnetwork 106 of computers serving 
a facility such as a medical facility or hospital. The source 
terminal 104 transmits the data packet 116, including the 
identifier 112 and the data access request 124 to a second 
processor or identifier database 128. The identifier database 
is preferably part of a second subnetwork 130 of computers. 
The second subnetwork 130 is typically a local area network 
under control of a second administrator. The second subnet- 
work 130 and the source subnetwork 106 may be located in 
different regions of the country. A communications link 
couples source terminal 104 and identifier database 128. In 
one embodiment, the communications link is an Internet link 
and/or private line. 

Identifier database 128 has the codes necessary to decrypt 
identifier 112. Encoding and decoding of identifier 112 may 
be done by a variety of methods. In one embodiment of the 
invention, source terminal 104 encrypts identifier 112 using 
a public key of identifier database 128. Identifier database 
128 decrypts the identifier 112 in data packet 116 using a 
corresponding private key. Because identifier database 128 
does not have tie decryption key needed to read information 
contained in data access request 124, the data access request 
information remains protected from the system administra- 
tor of identifier database 128 and subnetwork 130. 

Identifier database 128 uses the information contained in 
identifier 112 to generate (1) an access level indicating the 
access allowances of the user requesting data, and (2) an 
internal identifier identifying the individual or entity (the 
subject) corresponding to the requested data. Identifier 112 
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information serves as a search key to query a database, 
typically a table 132. In one embodiment, the user request- 
ing data, specified by user I.D. 118, is used to identify data 
for lookup in table 132 and determine the user's approved 
access level in relation to the individual identified in subject 
I.D. section 120. In particular, the subnetwork 130 deter- 
mines the types of data access activities that the user is 
permitted to perform on the records relating to the subject 
identified by subject I.D. 120. For example, the subnetwork 
130 may determine whether the user is a doctor currendy 
treating the identified individual. When a doctor is identified 
as treating an identified individual, the doctor is associated 
with a corresponding access level to permit the doctor to 
review x-ray, lab results, or add a progress note to the 
patient's records. The subnetwork 130 containing identifier 
database 128 associates an authorized user access level to 
the doctor. Identifier database 128 assigns a Subject Internal 
I.D., typically using a table such as table 133, to the 
individual identified in Subject I.D. Section 120 of identifier 
112. 

The identifier database 128 outputs a data packet 148 
including (1) a subject data section 144, and (2) a data access 
request 124. In one embodiment, the subject data section 
144 includes a user access level subsection 136 and an 
internal identifier stored in a subject internal identifier 
subsection 140. Subject data section 144 may also include 
the address of the originating source terminal 104. Because 
the material contained in subject data section 144 is typically 
incomprehensible to an interloper, it is not required that the 
subject data section 144 be encrypted. In maximum security 
systems, subject material in subject data 144 is encrypted 
with a code such that the subject material is only readable by 
data request database 152. In one embodiment of the 
invention, the identity of the user and the subject, the address 
of source terminal 104 and the time at which data was 
received and/or transmitted is stored in a log 156 in identifier 
database 128. 

Data request database 152 and the associated subnetwork 
154 receives data packet 148. When subject data 144 is 
encrypted, data request database 152 decrypts the subject 
data section 144 of data packet 148 and retrieves the subject 
internal I.D. 140 and the user access level 136. Data request 
database 152 also decrypts the data access request 124. Data 
access request 124 of data packet 148 is encrypted using a 
code readable only by data request database 152. In one 
embodiment of the invention, source terminal 104 encrypts 
data access request 124 with the public key of data request 
database 152 allowing data request database 152 to retrieve 
the data access request 124 using a corresponding private 
key. 

Data request database 152 determines if the user access 
level is sufficient to perform the type of data access 
requested in data access request 124 upon the records 
corresponding to the subject internal identifier 140. When 
the user has an appropriate user access level and is thus 
entitled to perform the operation, the data request database 
152 performs the requested operation upon records keyed to 
the internal identifier 140. 

In one embodiment, the data request database 152 does 
not contain the demographics, personal identifiers, and other 
personally identifiable information which can be used to link 
individuals or entities to the data contained in data records 
157. The known individually identifiable attributes 
including, for example, demographics and specific identifi- 
ers such as addresses are removed and stored in the identifier 
database 128. Thus, although the system administrator for 
data request database 152 and corresponding subnetwork 
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154 can access information corresponding to the requested of a second database, such as a data request database. The 
data, for example, that a record indicates a diagnosis of data access request contains information regarding the 
AIDS, the administrator cannot determine the name of the nature of the data request, such as delete a record, display 
patient who has this diagnosis. Only identifier database 128 laboratory result, and update financial information, 
contains information linking the public identity such as 5 In one embodiment of the invention, the entire data packet 
name and address of the patient to the internal identifier. It jg signed in block 212. Such encryption may be done with 
is conceivable that the splitting of data between the identifier a private key of the source terminal. Such encryption serves 
database 128 and the data request database 152 can be used to identify the source terminal 104 and prevent other termi- 
to store other sensitive data where it is desirable to prevent n als from mimicking source terminal 104. In alternative 
linkage between two data elements except by authorized 10 embodiments, authentication may be done by digitally sign- 
users- ing the data packet using one of many well-know digital 
After data request database 152 performs the requested signing algorithms such as RSA, ElGamal, and Rabin. In 
data access operations, such as retrieving a set of lab results block 216, the data packet is transmitted to a subnetwork 
from table 157, the database 152 uses source terminal I.D. including a computer containing a first database or identifier 
104 included in the subject data 144 to send a result set of 15 database. 

the data operations back to source terminal 104. The con- within the identifier database, the identifier information is 

nection between the data request database 152 and source decrypted in block 220. Typically, decryption is done using 

terminal 104 may be via Internet or the data may be the private key of the identifier database. In block 224, 

transmitted over a secured line. The result set can be identifier database uses the decrypted identifier information 

encrypted for the transmission to the source terminal, for 20 tQ look . up the individual for whom data is requested 

example, using the public key of source terminal 104. (subject), such as a patient in a hospital, and makes sure that 

In order to further improve security, in particular to such person or entity exists. The identifier database also 

prevent a single system administrator of either identifier verifies that the individual requesting the access has the 

database 128 or data request database 152 from sending authority to access the subject's information in block 224. 

queries to the system to try to determine internal identifi- 25 For example, the subject may be a patient in a hospital and 

cation codes or to perform unauthorized data access, each the person requesting the data may be a doctor. When used 

database maintains a log. The identifier database maintains in a hospital, the identifier database may check a table to 

a first log 156 which may store that a query was received make sure that the patient and the doctor represent a doctor- 

from a certain user at source terminal 104 and that a query patient pair in block 224. If the doctor and patient do not 

occurred at a specific time. Likewise, data request database 30 form a doctor-patient pair, access is not allowed in block 230 

152 maintains a second log 164 which records the subject and the source terminal is notified that the information is not 

internal I.D. operated upon, the destination to which the available in block 232. If the doctor and patient are a 

requested information was sent, and the source terminal I.D. doctor-patient pair, then access is allowed in decision block 

104 as well as the time at which information was transmitted 230 and the database retrieves the (1) appropriate privilege 

or received from identifier database 128. When there is a 35 level corresponding to the doctor-patient pair and (2) the 

question as to the integrity of the systems, a third party internal ID corresponding to the patient in block 236. 

auditor can compare the first log 156 and the second bg 164 The identifier database encrypts the internal ID, the privi- 

to determine whether there are irregularities. The preferred i ege level, and the source terminal address in block 240 for 

procedure for a third party audit utilizes a procedure such as transmission to a data request database in a separately 

check sum or hash function to transform these logs prior to administered subnetwork. The actual patient name as well as 

making them available to the auditor thereby protecting the me doctor name is stripped from the data, identified only by 

confidential identity of the user-subject pairs. ^ internal ID. In one embodiment of the invention, identi- 

Periodic reports can be generated by the identifier data- fier database encrypts the internal ID with the public key of 

base disclosing the identity of all users who accessed a given 4S the data request database. In block 244 of FIG. 2B, the data 

subject's records over a specified time interval. These packet including the internal identifier, user access level or 

reports can be sent direcdy to the subject or a person privilege level, along with the original encrypted data access 

designated by the subject for review. Any irregularities can request, is transmitted to the data request database in block 

then be corrected as appropriate. Inappropriate access of 244. In one embodiment, an entry is added to a log to 

records can thereby be identified in a timely manner and all 5{J document the transmission in block 244. The transmission 

users held accountable for their activities. may be through a dedicated line or virtual private network 

FIGS. 2A and 2B is a flow diagram 200 illustrating the to ensure data security and integrity. In one embodiment, the 

procedures used to implement the current, described inven- entire packet is encrypted and signed, 

tion. In block 204, a user at a source terminal requests data. In block 248, the data request database decrypts the 

The user may enter information such as a password, or other 55 information received from the identifier database. In block 

identifying information to indicate that the user is the entity 252, the data request database retrieves the patient's medical 

he or she claims to be. The source terminal encrypts the records file corresponding to the internal identifier. In deci- 

subject's identifying information such as the patient name sion block 256, the data request database determines if 

with a first code in block 208. In one embodiment, the access to the particular information in the file is allowed 

identifier is encrypted using a public key of an identifier 60 based on the access privilege level received. If access is not 

database. The identifier typically includes the address of the allowed, a notice is sent to the source terminal in block 260. 

terminal, and user information such as the name of the when the privilege level authorizes access to the specific 

person requesting the information. The identifier package information, the data request database performs the 

may also include the public key of the source terminal. requested operation and encrypts the result set in a data 

In block 208, the source terminal also encrypts the data 65 packet for transmission to the source terminal. In one 

access request using a second code. In one embodiment, the embodiment, the requested information is encrypted with 

data access request is encrypted using a second public key the public key of the source terminal in block 264. The 
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public key of the source terminal could have been received second identifier database 366. When either first identifier 

with the data access request. The encrypted data is then database 362 or second identifier database 366 confirms the 

transmitted back to the source terminal in block 268. The identity of user 300 and the subject of the query, the 

source terminal decodes the data and displays it to the identifier databases 362 and 366 forward the data access 

authorized user. 5 request to data request database 370. Data request database 

yj »• *j* .1 j * * * ^- * i * * * 370 provides user 300 with the response along data path 376. 

By dividing the data in a transaction request packet mto f v ... . c . . \. , « & ., t X , 4 

3 . & . -ui • i . 1° one embodunent of the mvention, dual identifier data- 

several parts, each part accessible to only one computer bases 362 , 366 may be used to mcrease security by reqmring 

system or corresponding subnetwork run by corresponding additional verification of the authenticity of user 300 by 

independent system administrators, subject confidentiality independent verificauon of different identification criteria at 

and data integrity of the information is preserved. Each 10 cacfa identificr databasc 362> 366. In the described 

database, such as identifier 128 and data request database embodiment, data request database 370 provides a response 

152 can be implemented on standard computer systems. on i y wnen both identifiable databases 362, 366 verify a 

These systems may be integrated using a network of direct request. Alternately, multiple identifier databases may be 

connections or if data transmissions are encrypted, using used to assign different users or subjects to corresponding 

publicly available Internet connections. 15 identifier databases as additional security mechanism or to 

The previous descriptions also show the data flow flowing l° ad balance the flow of data through the entire network, 

from a source terminal 104 to an identifier database 128 In system 400 illustrated in FIG. 4, a user 404 transmits 

through the data request database 152 back to the source a data request with user and subject identifying information 

terminal. FIGS. 3A and 3B illustrate this basic structure to a first identifier database 408 in a chain of identifier 

without and with the log monitor, respectively. However, the 20 databases Each identifier database 408, 412, 416 in the 

invention should not be limited to such a data flow as other chain verifies a specific unit of user or subject identifying 

data flows are possible. FIGS. 3C and 3D illustrate alterna- * For ™™? ]c > ^ I^^^^^^aT^ 

tive embodiments of information flow and data management fi name ° f * e Wh ™ the fiist ^ eD ^ r .^f 6 

, . & confirms the data, such as the name, the first identifier 

system design. ^ database 4q 8 f orwards the query to a second identifier 

FIG. 3A illustrates a bidirectional data flow between a database 412. Second identifier database 412 further verifies 

user 300 and an identifier database 308 along data path 304. me identity of the subject by comparing a second unit of 

When identifier database 308 accepts a query, the identifier information such as a Social Security number of the subject 

database 308 forwards the data request to a data request to the reC eived data. When the information is again verified, 

database 312. Data request database 312 provides a response $Q me identifier database 412 communicates the request 

along data path 316 to user 300. The illustrated configuration to a mird identifier database 416 which may compare a third 

of FIG. 3 A is a basic unit which does not include a log un jt 0 f data as a fingerprint to verify the identity of the 

monitor. subject of the query. 

FIG. 3B illustrates a use of an independent log monitor E ach identifier database keeps user 404 informed of the 
320 to monitor the information flow between identifier 3S query progress through the various identifier databases using 
database 308 and data request database 312. The log monitor return data paths 420, 424, 428. Records belonging to the 
compares the logs from identifier database 308 and data same subject (or user) are linked between identifier data- 
request database 312. Mismatches in the logs may result bases using an internal identification. For example, each 
from an user's unauthorized queries to the data request identifier database in an identifier database pair such as 
database 312 to obtain information without being routed ^ identifier database pairs 412, 416 share a common internal 
through the identifier database 308. Alternatively, this may identification. User 404 encrypts data for each identifier 
also result from attempts to query the identifier database and database 408, 412, 416 with a public key of that identifier 
link internal I.D. to identifying information. When such a database. When all three identifier databases 408, 412, 416 
discrepancy occurs, the log monitor 320 transmits a warning ver if y that the subject or user 404 is satisfactorily identified, 
to the user 300 or to an independent verification system. 45 data request database 432 receives the data access request 

FIG. 3C illustrates a system including a single user 300 and transmits the response to the user 404 along data path 

and multiple data request databases 350, 354. Multiple data 436. 

request databases divide and thereby reduce the amount of The function of an identifier database has been defined as 
information processed and controlled by each administrator verifying the identity of the user and subject and converting 
of each data request database 350, 354. Partitioning the 50 subject identifiers into an internal I.D. A data request data- 
information improves security. In FIG. 3C, the user at the base receives a data access request forwarded from an 
source terminal partitions and encrypts data for each of the identifier database and provides a response. For each valid 
data request database units 350, 354. The identifier database user-subject pair, each identifier database outputs at least one 
358 verifies the identity of user 300 and forwards the user or subject internal identification (I.D.), the internal I.D. 
partitioned and encrypted data to the respective first data 55 being an index that links adjacent identifier databases or a 
request database 350 and/or second data request database link used to connect information between an identifier 
354. In one embodiment of the invention, each data request database and a data request database. Data request databases 
database 350, 354 has its own corresponding public-private arc defined to be the databases which output the result of the 
encryption key-pairs to secure of transmission between user query, typically a complex data type which may include 
300 and each of the data request databases 350, 354. Each 60 ASCII text, charts, and other embedded information. In one 
data request database 350, 354 responds to the request and embodiment of the invention, the data request database is the 
transmits its response directly back to user 300 which last link in a cham which provides information directly to the 
recombines the responses. user. However, it is possible for a database to function as 
FIG. 3D illustrates dividing the identifier database to both an identifier database and a data request database. Such 
reduce the amount of information processed by each iden- 65 an embodiment is illustrated in FIG. 5 in which a single 
tifier database. In FIG. 3D, user 300 transmits an individual administrator controls a combination second identifier data- 
request to either or both first identifier database 362 and base and a data request database. 
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In the system 500 illustrated in FIG. 5, a user 504 
transmits a query to a first identifier database 508. When 
identifier database 508 verifies that user 504 is authorized to 
receive the requested data, the identifier database 508 for- 
wards the data access request to a data request database 
portion 512 of a combination database 516. The data request 
database 512 portion of combination database 516 provides 
a response to user 504. 

Identification information in data request database 512 
may serve as both identification information and/or data 
requested. For example, combination database 516 may 
have the task of maintaining fingerprint I.D. records. A data 
access request from identifier database 508 may contain 
instructions to add a new fingerprint record to the table of 
fingerprint records 516. At the successful completion of this 15 
operation, a message is sent back to user 504 from data 
request database 512. Alternatively, a fingerprint that iden- 
tifies a user or subject may be sent from identifier database 
508 to identifier database 520. After confirming the identity 
through matching with records in a table of fingerprint 
records 516, an internal I.D. is generated. When the data 
transfer is authorized, the identifier database 520 forwards 
the internal I.D. and the data access request to a second data 
request database 524 which provides the response back to 
user 504. 

Various permutations of identifier databases and data 
request databases can be combined or altered to implement 
data management systems with various performance, data 
security, data integrity and confidentiality trade offs. 

From the above description of drawings, it will be under- 
stood by those skilled in the art that the particular embodi- 
ments shown and described are for purposes of illustration 
only and are not intended to limit the scope of the invention. 
Those skilled in the art will recognize that the invention may 
be embodied in other specific forms without departing from 
its spirit or central characteristics. For example, although the 
description uses examples of one subject or patient, a 
number or entities or patients' records can be similarly 
accessed with one request. The limitations of the specific 
invention and its equivalent are defined by the claims which 
follow. 

What is claimed is: 

1. A method for managing data comprising: 
transmitting a packet of data including an identifier 45 

encrypted in a first code and a data access request 
encrypted with a second code to a first system, the data 
access request requesting data corresponding to the 
identifier, the first system configured to decode and 
authenticate the identifier and to forward the data 
access request with an internal index to a second 
system. 

2. The method of claim 1 wherein the first system is under 
a first administrative control and the second system is under 
a second administrative control. 

3. The method of claim 1 further comprising: 
encrypting the identifier using a public key of the first 

system; and 

encrypting the data access request using a public key of 
the second system. 

4. The method of claim 3 where in the identifier is 
digitally signed enabling authentication of an originator of 
the packet of data. 

5. The method of claim 1 wherein the identifier includes 
a subject representation. 



10 

6. The method of claim 1 wherein the first system updates 
a log indicating receipt of query or transmission of the 
packet of data and the second system updates a log indicat- 
ing receipt of the data access request or transmission of 
results of the data access request. 

7. An apparatus under control of a first administrator to 
process secure data comprising: 

an input port to receive an identifier encrypted in a first 
code and a data access request encrypted in a second 
code from a source, the data access request requesting 
data corresponding to the identifier; 
a processor to decrypt the first code and determine an 
internal identification corresponding to the identifier; 
and 

an output connection to output the internal identification 
and the data access request encrypted in the second 
code to a second apparatus including a second database 
operating under a second administrator. 

8. The apparatus of claim 7 wherein the processor verifies 
that a user issuing the data access request has an appropriate 
access level. 

9. The apparatus of claim 8 wherein the processor trans- 
mits the data access request to the second apparatus after a 

25 verification that the source has the appropriate access level. 

10. The apparatus of claim 7 further comprising: 
a memory to store a log, the log including records of 

internal identification codes transmitted to the second 
apparatus. 

11. The apparatus of claim 7 wherein the first code is 
decoded using a private key. 

12. A system to manage sensitive data comprising: 
a source terminal to receive a data access request, and 

output a data packet, the data packet including a first 
subsection of identifier information coded in a first 
code and a second subsection of request data coded in 
a second code, the data access request requesting data 
corresponding to the identifier information; 
an identifier database to receive the data packet and 
decode the identifier information, the identifier subnet- 
work retrieving an internal identifier based on the 
identifier information, and associating the internal iden- 
tifier with the request data coded in the second code; 
and 

a data request database to receive the internal identifier 
and the request data coded in the second code, the data 
request database to decode the request data and return 
a response to the source terminal. 

13. The system of claim 12 wherein the first code uses a 
public key of the identifier database and the second code 
uses a public key of the data request database. 

14. The system of claim 12 wherein the identifier database 
and the data request database are each a part of a corre- 
sponding subnetwork. 

15. A method of managing sensitive data comprising: 
receiving an internal identifier associated with a coded 

data request from an identifier database, the coded data 
request requesting data corresponding to the internal 
identifier; 

decoding the coded data request and performing the data 
request; and 

transmitting an output response to a source terminal. 
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